本发明涉及可配置的测试套件。具体地,提供了一种用于对包含微处理器的模块进行测试的系统和方法,其中所述微处理器具有编程环境。所述编程环境具有测试数据结构、配置数据结构、和监测数据结构,所述各数据结构中包含数据。至少一个测试数据实例与测试数据结构相关联,至少一个配置数据实例与配置数据结构相关联。配置数据实例是对微处理器的参数进行监测的诊断测试,并且监测数据结构创建测试数据实例,使得各测试数据实例与配置数据实例中的一个相对应。所述程序包括第一控制逻辑,该控制逻辑关联测试数据结构、配置数据结构和监测数据结构作为编程环境的核心基础架构部分的一部分,其中所述程序的核心基础架构部分是静态的。
1.一种对具有微处理器的控制模块进行监测的测试系统,包括:编程环境模块,其具有测试数据结构模块、配置数据结构模块、和监测数据结构模块,所述各个结构模块均包含数据;以及至少一个与所述测试数据结构模块相关联的测试数据实例、和至少一个与所述配置数据结构模块相关联的配置数据实例,其中,所述配置数据实例是对所述微处理器的参数进行监测的诊断测试,并且,所述监测数据结构模块创建所述测试数据实例,使得各测试数据实例与所述配置数据实例中的一个相对应,并且其中,所述测试系统包括:第一控制逻辑模块,其用于关联作为所述编程环境模块的核心基础架构部分的一部分的所述测试数据结构模块、所述配置数据结构模块和所述监测数据结构模块,其中,核心基础架构部分是静态的;第二控制逻辑模块,其是用于关联特定布置部分中的所述配置数据实例,其中,所述特定布置部分是动态的,诊断测试存储于特定布置部分内,该诊断测试能根据所使用控制模块的类型进行调整;第三控制逻辑模块,其用于执行所述配置数据实例,所述配置数据实例是对所述微处理器的参数中的一个进行监测的所述诊断测试;第四控制逻辑模块,其用来监测所述微处理器中的指示已经生成错误代码的数据信号,其中,所述错误代码是通过执行所述配置数据实例而生成;以及第五控制逻辑模块,其用于将所述诊断测试的结果存储在所述测试数据实例中。
2.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,各诊断测试以一偏移来布置,其中,所述偏移代表时间上的延迟。
3.如权利要求2所述的对具有微处理器的控制模块进行监测的测试系统,其中,所述时间上的延迟为1000毫秒。
4.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,所述测试数据结构模块包含32个诊断测试。
5.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,所述配置数据结构模块包含32个诊断测试。
6.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,所述测试系统包括执行模式模块,其中,所述执行模式模块根据所述微处理器是否处在启动模式、运行期模式和关闭模式的一个模式中来决定是否执行特定的诊断测试。
7.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,所述控制模块是安全气囊控制模块、车身控制模块、电池接触器模块、发动机控制模块、动力系控制模块、车辆集成控制模块、和变速器控制模块之一。
8.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,诊断故障代码标识与各错误代码相关联。
9.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,多个故障严重性级别与所述错误代码相关联。
10.如权利要求1所述的对具有微处理器的控制模块进行监测的测试系统,其中,至少一个配置数据实例被用于对所述微处理器的不同参数进行监测,所述至少一个配置数据实例是诊断测试。
11.如权利要求10所述的对具有微处理器的控制模块进行监测的测试系统,其中,所述诊断测试之一是堆栈使用测试,该测试表示了所述堆栈的使用百分率。
12.利用权利要求1-11中任一项所述的测试系统对具有微处理器的控制模块进行测试的方法,测试系统包括编程环境模块,编程环境模块具有测试数据结构模块、配置数据结构模块、和监测数据结构模块,所述各个结构模块均包含数据,其中,至少一个测试数据实例与所述测试数据结构模块相关联,至少一个配置数据实例与所述配置数据结构模块相关联,并且所述配置数据实例是对所述微处理器的参数进行监测的诊断测试,所述监测数据结构模块创建所述测试数据实例,使得各测试数据实例与所述配置数据实例中的一个相对应,所述方法包括:使所述测试数据结构模块、所述配置数据结构模块、所述监测数据结构模块与所述编程环境模块的核心基础架构部分关联,并且使所述配置数据实例与所述编程环境模块的特定布置部分关联,其中,所述核心基础架构部分是静态的,所述特定布置部分是动态的,诊断测试存储于特定布置部分内,该诊断测试能根据所使用控制模块的类型进行调整;执行所述配置数据实例,其中,所述配置数据实例是对所述微处理器的各参数中的一个参数进行监测的诊断测试;监测所述微处理器中的指示已经由正在执行的所述诊断测试生成错误代码的数据信号,其中,所述错误代码是通过执行所述配置数据实例而生成;以及将所述诊断测试的结果存储于所述测试数据实例中。
13.如权利要求12所述的方法,还包括这样的步骤:决定所述测试系统是否将继续监测所述微处理器中的指示已经生成错误代码的数据信号。
14.如权利要求12所述的方法,还包括:将各诊断测试以一偏移来布置的步骤,其中,所述偏移代表时间上的延迟。
15.如权利要求14所述的方法,其中,所述时间上的延迟为1000毫秒。
16.如权利要求12所述的方法,还包括这样的步骤:根据执行模式来执行特定诊断测试,其中,所述执行模式根据所述微处理器是否处在启动模式、运行期模式和关闭模式中的一个中来决定是否执行所述特定诊断测试。
17.如权利要求12所述的方法,还包括这样的步骤:建立与所述配置数据结构模块相关联的第一故障严重性级别,其中,如果所述微处理器生成了错误代码,那么所述第一故障严重性级别表示所述诊断测试中的一个测试的严重性级别,并且其中,所述第一故障严重性级别有8个严重性级别。
18.如权利要求17所述的方法,还包括这样的步骤:建立与所述监测数据结构模块相关联的第二故障严重性级别,其中,所述第二故障严重性级别表示所述第一故障严重性级别产生了8个严重性级别中的哪一个。
19.如权利要求18所述的方法,还包括这样的步骤:建立与所述监测数据结构模块的第二故障严重性级别相关联的8位组,并且其中,所述8位组的各个位与所述第一故障严重性级别的8个严重性级别中的一个相对应。
20.如权利要求12所述的方法,还包括这样的步骤:建立多个配置数据实例,所述配置数据实例是用于对所述微处理器的不同参数进行监测的诊断测试。技术领域
本公开涉及一种对微处理器进行测试的系统和方法,尤其涉及一种对包含程序(具有静态部分和动态部分)的微处理器进行测试的系统和方法。
背景技术
本节中的陈述仅仅提供与本公开相关的背景信息,并且可以或者可以不构成现有技术。健康监测测试系统通常用于检查由计算系统的微处理器的硬件或软件产生的错误。该测试系统中包括测试套件,该测试套件执行一系列测试以监测微处理器的不同参数。决定测试序列中包含哪些测试是设计测试套件时所要考虑的一个重要因素,因为执行太多的测试会是昂贵的而且也会浪费计算机内存及CPU处理量。同时,期望的是提供一种根据被测试微处理器的类型可重复使用的测试系统。测试套件可以包括多个测试,其中各测试均对微处理器的参数进行监测。根据所使用微处理器的类型,将不同类型的测试包含在测试套件中。例如,当与电池接触模块相比较时,车身控制模块通常将包含不同的测试。在一个方法中,测试套件仅包括在不同的微处理器之间共用的测试。然而,当采用此方法时,允许每片微处理器决定如何执行不包含在测试套件中的剩余的测试。在一个替代性实例中,将测试的超集存储于存储器中,其中测试的超集包含用于不同微处理器的所有不同测试。例如,测试套件可以包括车身控制模块以及电池接触模块所需的所有测试。然而,此方法会导致在这两种微处理器中执行不必要的测试。虽然当前的健康监测测试系统实现了其预期目的,但是仍然存在对新的改进的测试系统的需求,其从可重复使用性的观点来看显示出改进的性能并且减小被浪费的计算机内存和CPU处理量。
发明内容
本发明提供了一种具有包含编程环境的微处理器的控制模块。该编程环境具有测试数据结构、配置数据结构、和监测数据结构,这些数据结构中的每一个均包含数据。至少一个测试数据实例(dataxa0instance)与测试数据结构相关联,并且至少一个配置数据实例与配置数据结构相关联。配置数据实例是对微处理器的参数进行监测的诊断测试。监测数据结构创建测试数据实例,使得各测试数据实例与配置数据实例中的一个相对应。所述程序包括第一控制逻辑,该控制逻辑用于关联作为编程环境核心基础架构部分的一部分的测试数据结构、配置数据结构和监测数据结构,其中程序的核心基础架构部分是静态的。所述程序还包含第二控制逻辑,该控制逻辑用于关联程序的特定布置(deployment-specific)部分中的配置数据实例,其中程序的特定布置部分是动态的。所述程序还包括第三控制逻辑,该控制逻辑用于执行配置数据实例,配置数据实例是对微处理器各参数中的一个参数进行监测的诊断测试。所述程序包括第四控制逻辑,该控制逻辑用来监测微处理器中的指示已生成错误代码的数据信号。错误代码是通过执行配置数据实例而生成。最后,所述程序包括第五控制逻辑,该控制逻辑用于将诊断测试的结果存储于测试数据实例中。在本发明的一个实施例中,各诊断测试以一定的偏移来布置,其中所述偏移代表时间上的延迟。在本发明的另一个实施例中,时间上的延迟约为1000毫秒。在发明的又一个实施例中,测试数据结构包含32个诊断测试。在本发明的一个实施例中,配置数据结构包含多达32个的诊断测试。在本发明的另一个实施例中,该系统包括执行模式。执行模式根据微处理器是否处于启动模式、运行期模式和关闭模式中的一种模式来决定是否执行特定的诊断测试。在本发明的又一个实施例中,所述控制模块是安全气囊控制模块、车身控制模块、发动机控制模块、动力系控制模块、车辆集成控制模块、或者变速器控制模块中的一种。在本发明的一个实施例中,DTCxa0ID(诊断故障代码标识)与每个错误代码相关联。在本发明的一个实施例中,多个故障严重性级别与错误代码相关联。在本发明的另一个实施例中,将多个是诊断测试的配置数据实例用于监测微处理器的不同参数。在本发明的又一个实施例中,诊断测试中的一个测试是堆栈使用测试,该测试显示了堆栈使用百分率。在本发明的又一个实施例中,对具有微处理器的控制模块进行测试的方法包含程序。该程序包括测试数据结构、配置数据结构、和监测数据结构。至少一个测试数据实例与测试数据结构相关联,至少一个配置数据实例与配置数据结构相关联。配置数据实例是对微处理器的参数进行监测的诊断测试,监测数据结构创建测试数据实例使得各测试数据实例与配置数据实例中的一个数据实例相对应。所述方法包括使测试数据结构、配置数据结构、和监测数据结构与程序的核心基础架构部分关联的步骤。配置数据实例与程序的特定布置部分相关联,其中程序的核心基础架构部分是静态的,而程序的特定布置部分是动态的。所述方法也包括执行配置数据实例的步骤,其中配置数据实例是对微处理器各参数中的一个参数进行监测的诊断测试。所述方法还包括监测微处理器中的这样的数据信号的步骤,其中所述数据信号指示错误代码已经由正在被执行的诊断测试生成。错误代码是通过执行配置数据实例而生成。最后,所述方法包括将诊断测试的结果存储于测试数据实例中的步骤。在本发明的一个实施例中,所述方法还包括监测微处理器中的指示已经生成错误代码的数据信号的步骤。在本发明的另一个实施例中,所述方法还包括以一定的偏移来布置每个诊断测试的步骤,其中所述偏移代表时间上的延迟。在本发明的又一个实施例中,时间上的延迟大约为1000毫秒。在本发明的一个实施例中,所述方法还包括根据执行模式来执行特定诊断测试的步骤。执行模式根据微处理器是否处于启动模式、运行期模式和关闭模式中的一种模式来决定是否执行特定的诊断测试。在本发明的一个实施例中,所述方法还包括建立与配置数据结构相关联的第一故障严重性级别的步骤。如果微处理器生成错误代码,那么第一故障严重性级别则表示诊断测试中的一个测试的严重性级别。第一故障严重性级别中有8个严重性级别。在本发明的另一个实施例中,所述方法还包括建立与监测数据结构相关联的第二故障严重性级别的步骤。第二严重性级别表示了第一故障严重性级别产生了8个严重性级别中的哪个级别。在本发明的又一个实施例中,所述方法还包括建立与监测数据结构的第二故障严重性级别相关联的8位组的步骤。8位组中的每一位对应于第一故障严重性级别的8个严重性级别之一。在本发明的一个实施例中,所述方法还包括建立多个配置数据实例的步骤,所述多个配置数据实例是用以对微处理器不同参数进行监测的诊断测试。本发明提供以下技术方案:方案1.xa0一种具有微处理器的控制模块,包括:编程环境,其具有测试数据结构、配置数据结构、和监测数据结构,所述各个结构均包含数据;以及至少一个与所述测试数据结构相关联的测试数据实例、和至少一个与所述配置数据结构相关联的配置数据实例,其中,所述配置数据实例是对所述微处理器的参数进行监测的诊断测试,并且,所述监测数据结构创建所述测试数据实例,使得各测试数据实例与所述配置数据实例中的一个相对应,并且其中,所述程序包括:第一控制逻辑,其用于关联作为所述编程环境的核心基础架构部分的一部分的所述测试数据结构、所述配置数据结构和所述监测数据结构,其中,所述程序的核心基础架构部分是静态的;第二控制逻辑,其是用于关联所述程序的特定布置部分中的所述配置数据实例,其中,所述程序的所述特定布置部分是动态的;第三控制逻辑,其用于执行所述配置数据实例,所述配置数据实例是对所述微处理器的参数中的一个进行监测的所述诊断测试;第四控制逻辑,其用来监测所述微处理器中的指示已经生成错误代码的数据信号,其中,所述错误代码是通过执行所述配置数据实例而生成;以及第五控制逻辑,其用于将所述诊断测试的结果存储在所述测试数据实例中。方案2.xa0如方案1所述的系统,其中,各诊断测试以一偏移来布置,其中,所述偏移代表时间上的延迟。方案3.xa0如方案2所述的系统,其中,所述时间上的延迟约为1000毫秒。方案4.xa0如方案1所述的系统,其中,所述测试数据结构包含32个诊断测试。方案5.xa0如方案1所述的系统,其中,所述配置数据结构包含多达32个诊断测试。方案6.xa0如方案1所述的系统,其中,所述系统包括执行模式,其中,所述执行模式根据所述微处理器是否处在启动模式、运行期模式和关闭模式的一个模式中来决定是否执行特定的诊断测试。方案7.xa0如方案1所述的系统,其中,所述微处理器是安全气囊控制模块、车身控制模块、电池接触器模块、发动机控制模块、动力系控制模块、车辆集成控制模块、和变速器控制模块之一。方案8.xa0如方案1所述的系统,其中,诊断故障代码标识(DTCxa0ID)与各错误代码相关联。方案9.xa0如方案1所述的系统,其中,多个故障严重性级别与所述错误代码相关联。方案10.xa0如方案1所述的系统,其中,多个配置数据实例被用于对所述微处理器的不同参数进行监测,所述多个配置数据实例是诊断测试。方案11.xa0如方案10所述的系统,其中,所述诊断测试之一是堆栈使用测试,该测试表示了所述堆栈的使用百分率。方案12.xa0一种对具有微处理器的控制模块进行测试的方法,所述微处理器具有包括测试数据结构、配置数据结构、和监测数据结构的程序,其中,至少一个测试数据实例与所述测试数据结构相关联,至少一个配置数据实例与所述配置数据结构相关联,并且所述配置数据实例是对所述微处理器的参数进行监测的诊断测试,所述监测数据结构创建所述测试数据实例,使得各测试数据实例与所述配置数据实例中的一个相对应,所述方法包括:使所述测试数据结构、所述配置数据结构、所述监测数据结构与所述程序的核心基础架构部分关联,并且使所述配置数据实例与所述程序的特定布置部分关联,其中,所述程序的核心基础架构部分是静态的,所述程序的特定布置部分是动态的;执行所述配置数据实例,其中,所述配置数据实例是对所述微处理器的各参数中的一个参数进行监测的诊断测试;监测所述微处理器中的指示已经由正在执行的所述诊断测试生成错误代码的数据信号,其中,所述错误代码是通过执行所述配置数据实例而生成;以及将所述诊断测试的结果存储于所述测试数据实例中。方案13.xa0如方案12所述的方法,还包括这样的步骤:决定所述控制模块是否将继续监测所述微处理器中的指示已经生成错误代码的数据信号。方案14.xa0如方案12所述的方法,还包括:将各诊断测试以一偏移来布置的步骤,其中,所述偏移代表时间上的延迟。方案15.xa0如方案14所述的方法,其中,所述时间上的延迟约为1000毫秒。方案16.xa0如方案12所述的方法,还包括这样的步骤:根据执行模式来执行特定诊断测试,其中,所述执行模式根据所述微处理器是否处在启动模式、运行期模式和关闭模式中的一个中来决定是否执行所述特定诊断测试。方案17.xa0如方案12所述的方法,还包括这样的步骤:建立与所述配置数据结构相关联的第一故障严重性级别,其中,如果所述微处理器生成了错误代码,那么所述第一故障严重性级别表示所述诊断测试中的一个测试的严重性级别,并且其中,所述第一故障严重性级别有8个严重性级别。方案18.xa0如方案17所述的方法,还包括这样的步骤:建立与所述监测数据结构相关联的第二故障严重性级别,其中,所述第二严重性级别表示所述第一故障严重性级别产生了8个严重性级别中的哪一个。方案19.xa0如方案18所述的方法,还包括这样的步骤:建立与所述监测数据结构的第二故障严重性级别相关联的8位组,并且其中,所述8位组的各个位与所述第一故障严重性级别的8个严重性级别中的一个相对应。方案20.xa0如方案12所述的方法,还包括这样的步骤:建立多个配置数据实例,所述配置数据实例是用于对所述微处理的不同参数器进行监测的诊断测试。由本文所提供的描述,本发明的其它应用范围将变得显而易见。应当理解的是,本文中的描述和具体实例仅以说明为目的,而不是意图限制本公开的范围。
附图说明
本文所描绘的附图仅以说明为目的,而不是意图以任何方式限制本公开的范围。图1是具有微处理器的示例性控制模块的示意图,其中微处理器具有编程环境。图2是例示了图1中所示编程环境的方框图。图3是例示了图2中的编程环境的方框图。图4是例示了以延迟方式被执行的诊断测试的图表。图5是图1中所示程序的一部分的类图。
具体实施方式
以下的描述在性质上仅仅是示例性的,而不是意图限制本公开、其应用或使用。参照图1,其通过附图标记10表示示例性测试系统的示意图。测试系统10是用以对控制模块18进行监测,控制模块18优选是具有下列部件的电子控制装置:预编程的数字计算机或处理器、控制逻辑、用以存储数据的存储器、和至少一个I/O外围设备。所述控制逻辑包括用以监测、操控和生成数据的多个逻辑例程。控制模块18包含计算机可读存储介质20和程序22。在如图示的实施例中,程序22是面向对象的编程环境。程序22是用来操作数据,并且包含多种不同的数据结构。在如图示的实施例中,将数据结构表示为数据类,然而要理解的是,也可以采用存储并组织数据的任何类型的数据结构。程序22包含三种不同的数据结构,它们被显示为测试数据类26、测试配置类28、和健康监测类30。控制模块18可以是负责控制特定系统(例如,汽车的各种系统)的任何类型的嵌入式控制器。具体地,控制模块18可以是安全气囊控制模块、车身控制模块、电池接触模块、发动机控制模块、动力系控制模块、车辆集成控制模块、或者变速器控制模块。控制模块18包含微处理器、随机存取存储器(RAM)、只读存储器(ROM)、和输入/输出接口(未图示)。测试系统10被用来运行对与控制模块18相关联的微处理器的各种参数进行监测的诊断测试。诊断测试对由控制模块18的微处理器的硬件或软件所产生的错误进行检查,并且是控制模块18的健康状态的指示。现在参照图2,图中说明了如何将测试系统10的实例分组到一起从而能够形成可配置的、特定布置的测试套件。具体地,程序22包含可重复使用的核心基础架构40,该基础架构包含健康监测类30和与测试数据类26(图1)相关联的测试数据数组42。参照图1~图2,测试数据类26和测试配置类28也是核心基础架构40的一部分。核心基础架构40中所包含的数据是静态的。也就是说,在测试系统软件的使用寿命期间,核心基础架构40中所包含的数据一般不发生变化。测试系统10还包含特定布置结构44,该结构包含与测试配置类28相关联的测试配置数组46(图1)。特定布置结构44是动态的。也就是说,存储于特定布置结构44中的数据是可配置的,并且可以在测试系统软件的使用寿命期间被改变。在初始化期间,健康监测类30指向测试数据数组42和测试配置数组46,其中给健康监测类30分配了一个测试数据数组42以及一个测试配置数组46。测试配置数组46包含多个实例50(示于图1),可以根据被监测的控制模块18的类型来配置实例50。这些实例是用以对控制模块18的微处理器的特定参数进行监测的诊断测试。用以对诸如车身控制模块之类的微处理器进行监测的诊断测试通常不同于用以对诸如电池接触模块之类的微处理器进行监测的诊断测试。因此,可以根据所使用微处理器的类型来配置实例50。在一个实施例中,测试配置数组46包含多达32个的诊断测试50,然而要理解的是,也可以包括任意数量的诊断测试。测试数据数组42包含实例52(示于图1),实例52中的每个实例与测试配置数组46的实例50中的一个实例相对应。具体地,利用监测类30来创建对于测试配置数组46的每个实例50的测试数据数组42的一个实例52。测试配置数组46的实例50是由微处理器执行的诊断测试,并且各诊断测试的结果存储于测试数据数组42的实例52中。因此,测试数据数组42的实例52起到了存储测试配置数组46的各实例50的结果的容器的作用。在一个实施例中,测试数据数组42包含32个诊断测试52,然而要理解的是,也可以使用任意数量的测试。测试配置数组46的实例50可以被配置成使得任何类型或数量的诊断测试都可以包括在测试配置数组46内。这是因为测试配置数组46是存储于特定布置结构44的程序中,其中测试配置数组46是动态的。这意味着可以将测试配置数组46配置成适应不同类型的控制模块。参照表1,表中示出了用于不同类型控制模块18的一组示例性诊断测试。表1ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="549"/>例如,ECU1可以是车身控制模块,而ECU2可以是电池接触模块。然而,本领域技术人员将会理解,也可以使用其它类型的ECU。ECU1包含一组车身控制模块所特有的诊断测试,ECU2包含电池接触模块所特有的一组诊断测试。在如所示的实施例中,ECU每个均包含在ECU1和ECU2两者之间共用的诊断测试,这些测试是在表1中标记为GetHWIO_Pct_StackUsage、PerfmHWIO_b_ALU_Test、PerfmHWIO_b_ConfigRegTest、和GetHWIO_e_ClkSt的测试。各ECU也包括各ECU所特有的诊断测试。因为诊断测试是动态的并且存储于控制模块18的特定布置结构44(图2)中,所以各控制模块18可以具有可配置的一组诊断测试,该组诊断测试可以根据所使用的控制模块的类型进行调整。同时,各控制模块18也具有静态的核心基础架构40。存储于核心基础架构40中的数据可以在不同的控制模块18之间保持相同,但是特定布置结构44可以被修改以适应特定应用。在如表1中所示的实施例中,ECU1和ECU2分别包含6个诊断测试,然而要理解的是,也可以使用任何数量或类型的诊断测试。包含在ECU1和ECU2两者中的测试GetHWIO_Pct_SatckUsage返回堆栈使用百分率。包含在ECU1和ECU2两者中的测试PerfmHWIO_b_ALU_Test返回CPU的ALU测试的布尔通过(即合格)或失败。包含在ECU1和ECU2两者中的测试PerfmHWIO_b_ConfigRegTest返回CPU寄存器测试的布尔通过或失败。包含在ECU1和ECU2两者中的测试GetHWIO_e_ClkSt返回显示CPU时钟状态的枚举值。测试PerfmHWIO_e_MMUConfigTest包含在ECU1中并返回显示CPU内存管理单元配置的状态的枚举值。测试PerfmHWIO_e_MMUTest也包含在ECU1中,并且返回表示CPU内存管理单元的状态的枚举值。包含在ECU2中的测试GetHWIO_e_SPI_TestStatus返回显示串行外设接口(SPI)通信的状态的枚举值。测试GetHWIO_b_SeedKeyStatus也包含在ECU2中,并且返回点火源(seed)和钥匙(key)测试的布尔通过或失败。包含核心基础架构40的另一个优点是:能够在测试系统10的软件的使用寿命期间合并不同的测试,同时仍然可以保持相同的核心基础架构40。转向图3,如果需要改变测试配置数组46的一些或所有的诊断测试50,那么这可以通过用新的诊断测试50’来替换当前的诊断测试50来完成。在此方法中,包含在核心基础架构40中的软件保持不变,而仅仅需要对特定布置结构44中的软件进行修改。在一个实施例中,测试系统10可以配置成使测试对控制模块18的CPU利用率的影响最小化。具体地,参照图4,可以通过使构成测试配置数组46的诊断测试50的各测试(图2)延迟一预定量的时间,使得各诊断测试错开或偏移。使各测试偏移将会防止所有测试在相同时间运行。同时运行各诊断测试会导致控制模块18的CPU利用率的峰值。在如图4所示的实例中,各诊断测试1~6包含1000毫秒的时段。各诊断测试以100毫秒彼此偏移。参照图5,图中示出了控制模块18(图1)的程序22的类图。测试配置类28(TestCfg)包含多个属性92。属性92中的一个是DelayOffset属性,该属性允许以相同速率(即,相同的时段属性atu_Period)调度的测试配置类28的各诊断测试50发生偏移。也就是说,DelayOffset属性防止了具有相同时段属性atu_Period的所有诊断测试50被同时布置,这降低或防止CPU处理量的瓶颈。表2是说明了测试系统10的Executionxa0Mode(执行模式)属性的不同的可能值的示例性图表。测试系统10的Executionxa0Mode根据控制模块18的微处理器(图1)是否处于启动模式、运行期模式、或关闭模式、或者这些模式的任意组合来决定测试系统10是否将执行特定的诊断测试。存在8种Executionxa0Mode的可能组合,其中启动模式、运行期模式和关闭模式中的各模式可以是激活的或者是禁用的。参照图5,Executionxa0Mode是测试配置类28(TestCfg)的属性92。执行模式(Executionxa0Mode)包含8个不同的可能值,它们对应于Executionxa0Mode的8种不同组合,然而要理解的是,也可以采用Executionxa0Mode的较少组合。如果将Executionxa0Mode值设定为DisableExecution,那么启动模式、运行期模式、和关闭模式中的诊断测试将被禁用。如果将Executionxa0Mode值设定为OnlyStartupMode,那么诊断测试将仅在启动中进行。如果将Executionxa0Mode值设定为OnlyRunMode,那么诊断测试将仅在运行期模式中进行。如果将Executionxa0Mode值设定为ExcludeShutdownMode,那么诊断将仅在启动模式和运行期模式中运行。如果将Executionxa0Mode值设定为OnlyShutdownMode,那么诊断测试将仅在关闭模式中运行。如果将Executionxa0Mode值设定为ExludeRunMode,那么诊断测试将仅在启动模式和关闭模式中运行。如果将Executionxa0Mode值设定为ExcludeStartupMode,那么诊断测试仅在运行期模式和关闭模式中执行。最后,如果将Executionxa0Mode值设定为AllModes,那么诊断测试在启动模式、运行期模式和关闭模式中运行。表2ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="395"/>参照表3,表中示出了用于测试系统10的启动的顺序表。在设置期间,健康监测类30执行意图在设置期间运行的诊断测试。基于Executionxa0Mode的值(示于表2)来决定在设置期间运行的诊断测试。转向表4,表中示出了用于测试系统10的运行期模式的顺序表。在运行期模式期间,健康监测类30执行意图在运行期模式期间运行的诊断测试。基于Executionxa0Mode的值来决定在运行期模式期间所执行的诊断测试。最后,转向表5,表中示出了用于测试系统10的关闭的顺序表。在关闭期间,健康监测类30执行意图在关闭期间运行的诊断测试。基于Executionxa0Mode的值来决定在关闭期间运行的诊断测试。例如,如果将Executionxa0Mode的值设定为OnlyRunMode,那么仅执行用于运行期模式的顺序表,而用于启动和关闭的诊断测试则省略。表3ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="437"/>表4ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="433"/>表5ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="429"/>图5是控制模块18的程序22(图1)的类图86的图示。类图86包含测试数据类26、测试配置类28、和健康监测类30,这些类被表示为方框90。各方框90包含类的名称、属性92、和相应的类可以采取的操作94。类图86也示出了节点管理器96,该节点管理器是用于在类26、28和30之间进行数据通信。测试数据类26、测试配置类28、健康监测类30、和节点管理器96中的每一个均存储于程序22的软件的基础架构层。表6示出了列出测试配置类28(图5)的所有属性92(图5)的表。Execute的属性是测试配置类28(图1)的诊断测试50的指针。诊断测试50可以采用板级支持包(BSP)函数或者包装函数的形式。在如图所示的实施例中,诊断测试50的返回类型是无符号的8位数,其中没有通过的参数。诊断测试50的期望结果值是PassValue属性,该属性是无符号的8位数。TroubleCodeId属性具有相关的DTCxa0ID(诊断故障代码标识),其中TroubleCodeid是无符号的16位数。表6ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="554"/>DelayOffset属性允许以相同速率(即,相同的时段属性atu_Period)调度的测试配置类28中的各诊断测试50(图1)发生偏移。也就是说,DelayOffset属性防止具有相同的时段属性atu_Period的诊断测试50全部在相同时间布置。参照图4,属性atu_Period允许测试1~6中的各测试包含1000毫秒的时段。DelayOffset属性导致各测试以100毫秒彼此偏移。返回来参照表6,属性Executionxa0Mode表示是否诊断测试将在启动模式、运行期模式、关闭模式、或者这些模式的任意组合期间执行。属性FailureCount表示诊断测试50的容错。ProcessorRelated属性是当设定了健康监测类30的ProcessorFailure属性的值(表11)时是否应当考虑特定的诊断测试50的标志。属性FaultSeverityLevel是如果特定诊断测试失败则表示严重性级别的属性。健康监测类30也包括称为FaultSeverityLevel的属性(表11)。参照表11,健康监测类30的属性FaultSeverityLevel是用于表示失败的诊断测试具有何种严重性级别。表7示出了与测试配置类28的FaultSeverityLevel相关联的故障严重性级别的示例性列表。在如表7所示的实施例中,存在与健康监测类30的FaultSeverityLevel相关联的8位相对应的8种不同的故障严重性级别。例如,如果诊断测试50失败并且具有由测试配置类28的属性FaultSeverityLevel所确定的CeINF_y_FaultSeverityLvl4的故障严重性属性,那么健康监测类30的FaultSeverityLevel将第四位置位。可替代地,如果两个诊断测试50失败并且一个诊断测试具有CeINF_y_FaultSeverityLvl4的故障严重性属性而另一个诊断测试具有CeINF_y_FaultSeverityLvl6的故障严重性属性,那么健康监测类30的FaultSeverityLevel将第四位和第六位置位。表7ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="425"/>表8示出了列出由测试配置类28采用的所有操作94的表。测试配置类28的操作94调用以板级支持包(BSP)函数或包装函数的形式的诊断测试50,并且返回作为无符号8位数的诊断测试50。表8ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="415"/>现在转向表9,表中示出了说明测试数据类26的所有属性92的表。用测试配置类28的DelayOffet属性(示于表6)对DelayTimer属性进行初始化。用DelayOffet属性中所示的时间对DelayTimer属性进行初始化。每当测试数据类26的操作UpdateTimers被调用(UpdateTimers函数列于表10中所示的表中),DelayTimer属性被递减(即,直到零)。DelayTimer属性仅在测试系统10的运行模式中被考虑。用测试配置类28的属性“atu_Period”(示于表6)对属性ExecutionTimer进行初始化。然后,每当操作UpdateTimers被调用时(表10),ExecutionTimer被减少测试配置类28的atu_Period中所示的时间。具体地,如果DelayTimer属性值大于零,那么DelayTimer被减少atu_Period中所示的时间。否则,如果ExecutionTimer大于零,那么ExecutionTimer被减少atu_Period中所示的时间。ExecutionTimer属性仅在测试系统10的执行模式中被考虑。FailCounter属性是用于保留关于诊断测试50已连续失败了多少次的运行计数。如果FailCounter的值超过测试配置类28(示于表6)的属性FailureCount的阈值,那么将测试配置类28的对应的TroubleCodeId属性设定为特定的DTCxa0ID。表9ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="554"/>表10是说明了测试数据类26的操作94的表。UpdateTimers操作减少来自测试数据类26(表9)的atu_DelayTimer属性、测试数据类26(表9)的ExecutionTimer属性、或者两个属性atu_DelayTimer和ExecutionTimer的组合中规定的时间。然后,UpdateTimers操作返回表示ExecutionTimer是否已到期的布尔值。在一个实施例中,该布尔值具有表示为零的“假”值以及由任何非零值(例如数字1)所表示的“真”值。UpdateResult操作接收在控制模块18(图1)中执行的诊断测试的结果,并将该值与来自PassValue属性的期望结果进行比较,PassValue属性是测试配置类28的一部分(表6)。如果诊断测试的值不同于PassValue属性的值,那么UpdateResult使测试数据类26的FailCounter属性递增。然后,UpdateResult属性返回表示FailCounter是否超过测试配置类28的FailureCount属性的容错阈值(表6)的布尔值。“设置(Setup)”操作基于测试配置类28的相应实例的配置值来对测试数据类26的所有属性进行初始化。最后,“复位(Reset)”操作清除对所有故障的指示。表10ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="505"/>表11是说明健康监测类30的属性92的表。ProcessorFailure属性表示一个或多个诊断测试是否已失败。测试配置类28(表6)的ProcessorRelated属性是指示在设定健康监测类30的ProcessorFailure属性的值时是否应当考虑特定诊断测试50的标志。来自测试配置类28(表6)的属性ProcessorRelated是用以表示在设定健康监测类30的ProcessorFailure标志时是否应当考虑特定诊断测试。表11ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="509"/>FaultSeverityLevel属性表示与任何失败的诊断测试相关联的严重性级别。具体地,FaultSeverityLevel表示为了失败来自测试配置类28(示于表6)的属性FaultSeverityLevel需要的严重性级别。健康监测实例的FaultSeverityLevel属性的每一位是测试配置类28的所有实例(示于表6)的FaultSeverityLevel属性的按位的“或”。在表12中示出了如何将FaultSeverityLevel表示为信号的例子。表12ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="553"/>TestData属性是有多少实例或诊断测试50被执行的指示。具体地,测试数据数组42的实例52(示于图1)对应于测试配置数组46的实例50中的一个实例(示于图1),其中将各诊断测试的结果存储于测试数据数组42的实例52中。在如图示的实施例中,可以有测试配置类46的多达32个实例50是诊断测试。也有包含在测试数据数组42中的32个实例52,测试数据数组42被表示为a_h_itsTestData[32]。然而,要理解的是,也可以在测试数据数组42中包含任意预定数量的诊断测试。最后,p_h_itsTestConfig属性是诊断测试50(其是测试配置类28的实例)的指针。表13是说明了健康监测类30的操作94的表。PerformTest函数是用以表示是否存在通过执行测试配置类28的诊断测试而产生的任何错误。具体地,PerformTest函数调用测试数据类26的UpdateResult操作(示于表10)。UpdateResult操作接收诊断测试50的结果,并将该值与容错阈值进行比较。如果已超过了值则PerformTest函数接收来自UpdateResult操作的返回标志,并基于UpdateResult操作来设置或清除故障代码。具体地,基于测试配置类28的TroubleCodeID属性(表6)来设置或清除UpdateResult操作,TroubleCodeID属性具有相关联的DTCxa0ID属性。表13ntent="drawing" img-format="jpg" inline="no" orientation="portrait" wi="554"/>然后,健康监测类30的PerformTest函数调用测试配置类28的特定诊断测试50。如果设定了测试配置类28的ProcessorRelated属性的标志(表6),这就意味着当设定了健康监测类30的ProcessorFailure标志时应当考虑测试配置类28的特定诊断测试50(表11)。因此,如果设定了测试配置实例的ProcessorFailure属性,并且如果特定的测试配置实例已使相关联的诊断测试失败,那么设定健康监测实例的ProcessorFailure属性,从而表示已发生了错误。Initialize函数调用测试数据类26的各实例52的Setup函数(表10)从而对测试数据类26的属性进行初始化,其中测试数据类26的各实例52是基于测试配置类28的相应的实例或诊断测试50。然后,Initialize函数对与诊断测试50中的一个测试相关联的测试配置类28的各Executionxa0Mode属性(表6)进行检查,并且如果意图在测试系统10的启动期间运行,那么将执行诊断测试50。Run函数对测试配置类28的各诊断测试50的测试配置类28的Executionxa0Mode属性进行检查,如果假设诊断测试50在测试系统10的运行模式期间运行,则调用测试数据类26的UpdateTimers函数(表10)。如果UpdateTimers函数到期,则执行诊断测试50。Terminate函数对测试配置类28的各诊断测试50的测试配置类28的Executionxa0Mode属性进行检查,如果诊断测试50意图在测试系统10的关闭期间运行,则执行诊断测试50。继续参照图1~图5,其总体上描述了对与控制模块18(图1)相关联的微处理器进行测试的方法。该方法始于第一步骤,其中控制模块18包含这样的控制逻辑,该控制逻辑用于关联程序22的核心基础架构40中的测试数据类26、测试配置类28、和健康监测类30。核心基础架构40中所包含的数据是静态的。也就是说,在测试系统软件的使用寿命期间,核心基础架构40中所包含的数据一般不发生变化。然后,所述测试方法可以进入第二步骤。在第二步骤,控制模块18包含这样的控制逻辑,该控制逻辑用于关联程序22的特定布置部分44中的配置数据实例50。具体地,参照图1~图2,测试配置数组46的实例50是用以对控制模块18的微处理器的参数进行监测的诊断测试。特定布置结构44是动态的。也就是说,在测试系统软件的使用寿命期间,存储于特定布置结构44中的数据是可配置的并且可以改变。参照表1,表中示出了用于不同类型控制模块18的一组示例性诊断测试。具体地,ECU1包含ECU1所特有的一组诊断测试,而第二ECU2包含ECU2所特有的一组诊断测试。例如,ECU1可以是车身控制模块,而ECU2xa0可以是电池接触模块。因为将诊断测试存储于控制模块18的动态的特定布置结构44内,所以各控制模块18可以具有可配置的一组诊断测试,该组诊断测试可以根据所使用控制模块的类型进行调整。然后,所述方法可以进入第三步骤。在第三步骤中,控制模块18包含用以执行配置数据实例50的控制逻辑。也就是说,控制模块18执行与测试配置类28的测试配置数组46相关联的诊断测试50(图1~图2)。所述诊断测试是用于对控制模块18的微处理器的特定参数进行监测。然后,所述方法可以进入第四步骤。在第四步骤,控制模块18包含这样的控制逻辑,该控制逻辑是用来监测控制模块18中的指示已经生成错误代码的数据信号。具体地,表13说明了健康监测类30的操作94,其中PerformTest函数是用以表示是否存在通过执行测试配置类28的诊断测试而产生的任何错误。PerformTest函数调用测试数据类26的UpdateResult操作(示于表10)。UpdateResult操作接收诊断测试50的结果,并将该值与容错阈值进行比较。PerformTest函数接收来自UpdateResult操作的表示了是否超过了容错阈值的返回标志,并基于该UpdateResult操作来设定或清除故障代码。然后,健康监测类30的PerformTest函数调用测试配置类28的特定的诊断测试50。如上所述,如果设定了测试配置类28的ProcessorRelated属性(表6)的标志,那么这就意味着当设定健康监测类30的ProcessorFailure标志时(表11)应当考虑测试配置类28的特定的诊断测试50。因此,如果设定了测试配置实例的ProcessorFailure属性,并且如果特定的测试配置实例已失败,那么设定健康监测实例的ProcessorFailure属性,从而表明在控制模块18的微处理器中的一个微处理器中已发生了错误。一旦控制模块18已确定了诊断测试中的任意诊断测试是否失败,那么所述测试方法可进入第五步骤。在第五步骤,控制模块18包含控制逻辑,该控制逻辑是用于将诊断测试的结果存储于测试数据数组42的实例52中。测试数据数组42的各实例52(示于图1)均与测试配置数组46的实例50中的一个相对应。监测类30是用于为测试配置数组46的各实例50创建测试数据数组42的一个实例52。将各诊断测试的结果存储于测试数据数组42的实例52中。因此,测试数据数组42的实例52起到了存储测试配置数组46的各实例50的结果的容器的作用。然后,所述测试方法进入第六步骤。在第六步骤,控制模块18包含这样的控制逻辑,该控制逻辑确定是否应该继续对控制模块18的微处理器进行监测。如果确定应该继续对微处理器进行监测,那么所述测试方法返回至第二步骤。如果确定无需再对微处理器进行监测,那么所述方法可以终止。是否应该继续对微处理器进行监测取决于Executionxa0Mode的值(示于表2)以及测试系统10是否处于启动模式、运行时期模式、或关闭模式、或者这些模式的任意组合中。例如,参照表2,如果将Executionxa0Mode值设定为OnlyStartupMode,那么诊断测试将仅在启动期间进行。因此,一旦测试系统10已确定在启动期间诊断测试是否生成了错误代码,那么所述方法将终止并且不返回至第二步骤。在另一个实例中,如果将Executionxa0Mode值设定为AllModes,那么诊断测试则在启动模式、运行期模式和关闭模式中进行。因此,一旦测试系统10已确定在启动期间诊断测试是否生成了错误代码,那么所述方法返回至第二步骤。然后,在运行期模式及关闭模式中,再次执行所述测试方法。如果所述测试方法在关闭模式期间处在第六步骤,那么所述测试方法则终止。本发明的描述在性质上仅仅是示例性的,因而不背离本发明要旨的变型都是在本发明的范围内。这些变型不被认为是背离了本发明的精神和范围。